在上一篇文章中，提到了如何透過IoC的設計，以及Stub Object的方式，來獨立測試目標物件。
這一篇文章，則要說明有哪些設計物件的方式，可以讓測試或需求異動時，更容易抽換。
並說明這些方式有哪些特性，供讀者朋友們在設計時，可以選擇適合自己情境的方式來使用。
上一篇文章：[Day 5]如何隔離相依性 - 基本的可測試性
本系列文章專區
當呼叫目標物件的方法時，期望目標物件可以不必關注相依於哪些實體物件，而只需要相依於某個介面，透過這樣的方式來達到設計的彈性與可獨立測試性。
那麼，有哪一些方式可以達到這樣的目的呢？
＠建構式（constructor）
程式碼如下：
public class Validation
{
private IAccountDao _accountDao;
private IHash _hash;
public Validation(IAccountDao dao, IHash hash)
{
this._accountDao = dao;
this._hash = hash;
}
public bool CheckAuthentication(string id, string password)
{
var passwordByDao = this._accountDao.GetPassword(id);
var hashResult = this._hash.GetHashResult(password);
return passwordByDao == hashResult;
}
}
Autowiring is an automatic detection of dependency injection points
這邊的dependency injection points在這例子，指的就是建構式。以Unity為例，在UnityContainer取得目標物件時，會自動尋找目標物件參數最多的建構式。並針對每一個參數的型別，繼續在UnityContainer中尋找對應的實體物件，直到目標物件組合完畢，回傳一個完整的目標物件。
由建構式傳入相依介面的實體物件，是一個很通用的方式。因此在結合許多常見的DI framework，不需要在額外處理。
另外，倘若是許多建構式，也可能造成要呼叫A方法時，應選用A對應的建構式，但在使用物件上，可能會用錯建構式而不自知，若方法中沒有正確的防呆，則可能出現錯誤。（請搭配單元測試的測試案例來輔助）
最後，與原本直接相依的程式碼相比較，目標物件的相依物件因此暴露出來，交由外部決定，而喪失了一點封裝的意味。而使用端也不一定知道，要取用此物件時，應該要注入哪些相依物件。（請使用Repository Pattern或DI framework來輔助）
＠公開屬性（public setter property）
而公開屬性通常只會將setter公開給外部設定，getter則設定為private。原因很簡單，外部只需設定，而不需取用。就像公開建構式，在使用物件之前先傳入初始化物件必備的資訊，但目標物件可能將這些資訊，存放在private的filed或property中，而不需再提供給外部使用。
程式碼如下：
public class Validation
{
public IAccountDao AccountDao { private get; set; }
public IHash Hash { private get; set; }
public bool CheckAuthentication(string id, string password)
{
if (this.AccountDao == null)
{
throw new ArgumentNullException();
}
if (this.Hash == null)
{
throw new ArgumentNullException();
}
var passwordByDao = this.AccountDao.GetPassword(id);
var hashResult = this.Hash.GetHashResult(password);
return passwordByDao == hashResult;
}
}
好處：
同樣的，public property也是常見的dependency injection points，所以也有許多DI framework支援。另外則是不需要對建構式進行改變，或增加新的建構式。對過去已經存在的legacy code的影響，會比建構式的方式小一點點（但幾乎沒有太大差異）。
顧慮點：
最常見的情況，就是使用目標物件時，相依介面應有其對應執行個體，但卻因為使用端沒有設定public property，導致使用方法時出現NullReferenceException，這種情況也怪不了使用端，因為使用端極有可能本就不瞭解這個方法中，有哪些相依物件。
解決方式與建構式的建議雷同，首先當然要有測試程式來說明（測試程式就是物件使用說明書），另外取得目標物件，仍可透過Repository Pattern，讓使用端無須瞭解目標物件的相依關係。
並且在方法中使用相依介面前，應檢查其是否為Null，若為Null，則代表參數設定錯誤，進行error handling，避免已經發生錯誤仍執行許多不應執行的程式碼。或是在property的getter時，檢查是否為null或當為null時，給予一預設值，以避免方法無法正常執行。（視實際需求而定）
另外，公開屬性的方式，也如同公開建構式一般，破壞了一點點物件封裝的用意。但這兩者，都是IoC設計會帶來的影響。
＠呼叫方法時傳入參數
程式碼如下：
public bool CheckAuthentication(IAccountDao accountDao, IHash hash, string id, string password)
{
var passwordByDao = accountDao.GetPassword(id);
var hashResult = hash.GetHashResult(password);
return passwordByDao == hashResult;
}
2.好處：
不必再擔心要先初始化哪些property，或呼叫哪一個建構式。當要呼叫某一個方法，其相依的物件，就是得透過參數來給定。基本上也不太需要擔心使用上造成困擾或迷惑。
另外，方法的參數過多，在使用上也會造成困擾。而且會影響到legacy code的呼叫端，需要全面跟著異動，才能編譯成功。
而且透過參數的方式，DI framework支援度較低。
但這不代表，就不能在方法參數中，傳入相依物件。在.net framework還是有許多這樣的設計，例如：List<T>.Sort 方法 (IComparer<T>)。這樣的設計方式，通常要確保該方法相依相當明確、穩固，避免上述問題。
by the way, 這個方式是可以與其他方式共存的，所以在設計物件時，可衡量搭配使用。
＠可覆寫的保護方法
先來看看原本直接相依物件，無法測試的程式，程式碼如下：
public class Validation
{
public bool CheckAuthentication(string id, string password)
{
var accountDao = new AccountDao();
var passwordByDao = accountDao.GetPassword(id);
var hash = new Hash();
var hashResult = hash.GetHashResult(password);
return passwordByDao == hashResult;
}
}
接下來，我們只用簡單的物件導向概念：繼承、覆寫，就可以對Validation物件的CheckAuthentication方法進行測試。不相信嗎？繼續往下看下去。
首先，一定要記得，把new物件的動作抽離高層抽象的context中。（可以透過extract method的方式抽離）
程式碼如下：
public class Validation
{
public bool CheckAuthentication(string id, string password)
{
var accountDao = GetAccountDao();
var passwordByDao = accountDao.GetPassword(id);
var hash = GetHash();
var hashResult = hash.GetHashResult(password);
return passwordByDao == hashResult;
}
private Hash GetHash()
{
var hash = new Hash();
return hash;
}
private AccountDao GetAccountDao()
{
var accountDao = new AccountDao();
return accountDao;
}
}
沒什麼改變，對吧？
接下來，將兩個new物件的方法，宣告為protected virtual，代表子類別可以繼承與覆寫該方法。程式碼如下：
protected virtual Hash GetHash()
{
var hash = new Hash();
return hash;
}
protected virtual AccountDao GetAccountDao()
{
var accountDao = new AccountDao();
return accountDao;
}
另外，將要使用到Hash與AccountDao的方法，也要宣告為virtual。程式碼如下：
public class AccountDao
{
public virtual string GetPassword(string id)
{
throw new NotImplementedException();
}
}
public class Hash
{
public virtual string GetHashResult(string password)
{
throw new NotImplementedException();
}
}
到這邊，都不影響外部使用目標物件的行為，我們只是在重構物件的內部方法罷了。事實上，我們可測試性的動作也準備完畢了。（當然，建議還是要相依於介面，實作介面要顧慮的點，比繼承類別要輕鬆的多）
接下來把目光切到測試程式，該如何對CheckAuthentication方法進行測試。
首先，將上一篇文章的StubHash改繼承自Hash，StubAccountDao改繼承自AccountDao，並將原本public的方法，加上override關鍵字，覆寫其父類方法內容。程式碼如下：
public class StubAccountDao : AccountDao
{
public override string GetPassword(string id)
{
return "91";
}
}
public class StubHash : Hash
{
public override string GetHashResult(string password)
{
return "91";
}
}
不難，對吧。接下來，建立一個MyValidation的class，繼承自Validation。並覆寫GetAccountDao()與GetHash()，使其回傳Stub Object。程式碼如下：
public class MyValidation : Validation
{
protected override AccountDao GetAccountDao()
{
return new StubAccountDao();
}
protected override Hash GetHash()
{
return new StubHash();
}
}
也不難，對吧。接下來，來設計單元測試，程式碼如下：
[TestMethod()]
public void CheckAuthenticationTest()
{
Validation target = new MyValidation();
string id = "id隨便啦";
string password = "密碼也沒關係";
bool expected = true;
bool actual;
actual = target.CheckAuthentication(id, password);
Assert.AreEqual(expected, actual);
}
原本初始化的測試目標為Validation物件，現在則為MyValidation物件。裡面唯一不同的部分，只有覆寫的方法內容，其餘MyValidation就等同於Validation。
偵錯測試一下，就可以確認，程式碼就跟之前使用IoC的方式執行沒有太大的差異。請見下圖：
好處：
這個方式最大的好處，是完全不影響外部使用物件的方式。僅透過protected與virtual來對繼承鏈開放擴充的功能，並且透過這樣的方式，就使得原本直接相依而導致無法測試的問題，獲得解套。
顧慮點：
這是為了測試，且legacy code所使用的方式，而不是良好的物件導向設計的方式。IoC的用意在於介面導向與擴充點的彈性，所以當可測試之後，倘若重構影響範圍不大，建議讀者朋友還是要將物件改相依於介面，透過IoC的方式來設計物件。
by the way, 同樣為了解決直接相依物件，甚至相依於static方法、.net framework本身的物件（如DateTime.Now）而導致無法測試的問題，還有另外一個方式，稱為fake object。這在後面的文章，會再進行較為詳盡的介紹。
＠結論
以上幾種用來測試的方式，希望對各位讀者在不同情境下的設計，可以有所幫助。
而許多延伸的議題，在這系列文章並不會多談，但在實務應用面上，卻是相當重要的配套措施。例如一再提到的DI framework, Repository Pattern，以及透過測試程式來說明物件的使用方式，請讀者在實務設計系統時，務必瞭解這些東西如何讓系統設計更加完整。
下一篇文章，將介紹怎麼樣可以避免每次手工刻這麼囉唆的stub物件，怎麼針對static或.net framework本身的物件進行隔離，怎麼針對物件與相依介面互動的情況進行測試。
昨晚沒等到~
今天還是讓我做到沙發了~~~YA~
期待好久了
請問一下，您是我plurk or Facebook上的好友嗎？
不然怎麼會這麼快就發現文章發出去了 
嘿嘿因為假日不用上班~我一直守在電腦前等待你的文章阿
阿~偶像~偶像~
iThome鐵人賽
看影片追技術